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REMARKS 

Claims 1-36 were pending. Claims 15, 23, and 29 have been cancelled. Claims 1, 
14, 16, 22, 28, 35, and 36 have been amended to clarify the nature of the presently 
claimed invention. Claims 37-39 have been added. Support for these new claims may be 
found in the Specification at least in FIGs. 15a, 15b, and 15c, in the accompanying 
description, and in the pending claims. Accordingly, claims 1-39 remain pending in the 
application after entry of the present amendment. 

35 U.S.C. $ 102(e) and $ 103(a) Rejections 

In the present Office Action, claims 1-7, 16-22, 30, and 33-36 stand rejected 
under 35 U.S.C. § 102(e) as being anticipated by U.S. Patent 6,836,785 (hereinafter 
"Bakshi"). In addition, claims 8-15 and 23-29 stand rejected under 35 U.S.C. § 103(a) as 
being unpatentable over Bakshi in view of U.S. Patent 5,878,224 (hereinafter "Smith"). 
In addition, claims 31 and 32 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Bakshi and "Getting Started with the Java Dynamic Management Kit 
4.2." Applicant has reviewed the cited references and notes that all of the above 
rejections depend on the teachings of Bakshi. Applicant has amended the independent 
claims to clarify the nature of the presently claimed invention and submits each of the 
pending claims recite features neither disclosed nor suggested by the combination of cited 
art. Accordingly, Applicant traverses the above rejections and requests reconsideration in 
view of the following comments. 

Claim 1, as amended, recites a method that includes, in part: 

"b 1 . evaluating a first condition, which involves whether the server 
operation parameter passes a first threshold value in a first 
direction, and 
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b2. evaluating a second condition, which involves whether the server 
operation parameter passes a second threshold value in a second 
direction, wherein the second condition includes determining that 
the second direction is opposite to the first direction, and extends 
from the first threshold value to the second threshold, ..." 
(Emphasis added). 



It is noted that evaluating the second condition explicitly includes a determining 
step that the second direction is opposite to the first direction . 



On pages 5-6 of the present Office Action, the Examiner suggests Bakshi teaches 



"a variety of conditions that are monitored to determine if a value has 
passed in either direction (e.g., Bakshi col. 2, lines 13-25 and col. 5, lines 
3-29; see also col. 4, lines 44-59). Applicant has not offered a persuasive 
reason as to why exceeding or failing below percentage threshold values 
fails to meet the claim limitation of 'pass[ing] a second value in a second 
direction.' ..." 

However, as noted above, claim 1 now recites that the second condition includes 
determining that the second direction is opposite to the first direction. No such 
determination is found in Bakshi. While it may be true that different conditions result in 
passing a threshold in different directions in Bakshi, there is no mention of determining 
the direction for a particular threshold-passing event in relation to any other threshold- 
passing event. Accordingly, Applicant finds no teaching or suggestion in Bakshi of 
"evaluating a second condition, which involves whether the server operation parameter 
passes a second threshold value in a second direction, wherein the second condition 
includes determining that the second direction is opposite to the first direction," as is 
recited in claim 1 . 



For at least these reasons, claim 1 is patentably distinguishable from the cited art. 
As claims 16, 35, and 36 include features similar to those discussed above, each of claims 
16, 35, and 36 is patentably distinguishable for at least the above reasons as well. 
Further, as each of the dependent claims includes at least the features of the independent 
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claim upon which it depends, each of the dependent claims is believed to be patentably 
distinguishable for at least the above reasons as well. 



In addition to the above, the dependent claims recite further features not found in 
the cited art. For example, claim 3 recites: 



"The method of claim 1, wherein the third condition of step c. comprises the fact 
the second condition has not been verified during a grace period after the first 
condition has been verified, and the fourth condition of step d. comprises the fact 
the second condition has been verified after the third condition has been verified." 



On page 6 of the present Office Action, the Examiner suggests Bakshi teaches the 
third condition at col. 4, line 54-col. 5, line 2, where a grace period is calculated. 
However, Bakshi merely teaches that to avoid false overload indications a first condition 
may be re-evaluated after a predetermined time. More particularly, Bakshi discloses: 



"As described above, the overload status of the processor 300 can be 
determined based on an arrival rate of the requests and a processing rate of 
the processor 300 or by any other well known methods. As further 
described above, the overload status of the processor 300 can be 
determined by the controller 200. For example, if the processing rate of 
incoming requests is 10 requests/minute and the incoming call rate is 5 
requests/minute, then the processor is not overloaded because the 
processor 300 is able to handle all incoming requests. Alternatively, if the 
processing rate remains at 10 requests/minute, then the incoming request 
rate increases to 15 requests/minute, then after a predetermined period of 
time, the processor 300 can be determined to be overloaded. 

The predetermined period of time can be as small as no time at all, or as 
large as necessary. The predetermined time can be set based on design 
requirements for the system, such as processing speed of the processor 
300, the buffer size of the variable size buffer 306, and a desired delay 
time for requests waiting in a queue. The predetermined time limit is 
mainly to avoid the detection of a false overloaded state of the processor 
when the incoming call rate is merely temporarily experiencing a spike in 
the incoming request traffic volume, as opposed to a longer and sustained 
increase in incoming request traffic." (Bakshi, col. 4, line 45 - col. 5, line 
2). 
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As may be seen from the above, Bakshi describes evaluating the incoming request 
rate and comparing it to the processing rate, both before and after the predetermined 
period of time. Therefore, Bakshi verifies a single condition before and after the grace 
period. In contrast, claim 1 recites two conditions that, as discussed above, are different 
at least because the second condition includes determining that the second direction is 
opposite to the first direction. 

Alternatively, Bakshi discloses comparing buffer usage to a threshold. However, 
these comparisons are not part of the determination of an overload condition to which the 
grace period applies (see Bakshi, block 420 in FIG. 2). Instead, the threshold to which 
buffer usage is compared is determined by whether or not a server is overloaded 
irrespective of any previous buffer usage evaluations. Accordingly, Applicant finds no 
teaching or suggestion in Bakshi that "the third condition of step c. comprises the fact the 
second condition has not been verified during a grace period after the first condition has 
been verified," as is recited in claim 3. For at least these additional reasons, claim 3 is 
patentably distinguishable from the cited art. As claim 18 includes features similar to 
those discussed above, claim 18 is patentably distinguishable for at least the above 
reasons as well. 

Further, claim 15 recites, the method of claim 14 "wherein the third rate is not 
lower than the first rate." Smith col. 8, lines 13-34 is cited as teaching these features. 
However, Applicant finds no mention anywhere in Smith of performing measurements at 
different rates. Instead, Smith merely discloses measurements that are performed over a 
"measurement interval." Choosing a particular duration for a measurement interval 
would result in a corresponding rate. However, Smith is silent as to any particular choice 
of a measurement interval and does not disclose plural measurement intervals of different 
durations. 

Still further, new claim 37 recites a device configured to: 
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"compare values of the server operation parameter to a first threshold 
value; 

in response to detecting that the server operation parameter has passed the 
first threshold value in a first direction: 
compare values of the server operation parameter to a second 

threshold value, wherein the second threshold value is 

different from the first threshold value ; 
start rejection of input requests in response to detecting the server 

operation parameter has not passed the second threshold 

value in a direction opposite the first direction during a 

grace period; and 
terminate rejection of input requests in response to detecting the 

server operation parameter has passed the second threshold 

value in a direction opposite the first direction during the 

grace period." (Emphasis added). 

It is noted that comparisons of the values of the server operation parameter to a 
second threshold value is in response to detecting that the server operation parameter has 
passed the first threshold value in a first direction and the second threshold value is 
different from the first threshold value. In contrast, the teachings of Bakshi differ from 
claim 37 in that Bakshi evaluates a single condition to determine if the server is 
overloaded; for example, whether or not the rate of incoming requests is greater than a 
processing rate of the server for a prolonged period of time. The processing rate of the 
server is analogous to a single threshold. Bakshi teaches that to avoid false overload 
indications a first condition may be re-evaluated after a predetermined time. More 
particularly, Bakshi discloses: 

"As described above, the overload status of the processor 300 can be 
determined based on an arrival rate of the requests and a processing rate of 
the processor 300 or by any other well known methods. As further 
described above, the overload status of the processor 300 can be 
determined by the controller 200. For example, if the processing rate of 
incoming requests is 10 requests/minute and the incoming call rate is 5 
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requests/minute, then the processor is not overloaded because the 
processor 300 is able to handle all incoming requests. Alternatively, if the 
processing rate remains at 10 requests/minute, then the incoming request 
rate increases to 15 requests/minute, then after a predetermined period of 
time, the processor 300 can be determined to be overloaded. 

The predetermined period of time can be as small as no time at all, or as 
large as necessary. The predetermined time can be set based on design 
requirements for the system, such as processing speed of the processor 
300, the buffer size of the variable size buffer 306, and a desired delay 
time for requests waiting in a queue. The predetermined time limit is 
mainly to avoid the detection of a false overloaded state of the processor 
when the incoming call rate is merely temporarily experiencing a spike in 
the incoming request traffic volume, as opposed to a longer and sustained 
increase in incoming request traffic." (Bakshi, col. 4, line 45 - col. 5, line 
2). 



As may be seen from the above, Bakshi describes evaluating the incoming request 
rate and comparing it to the processing rate, both before and after the predetermined 
period of time. Therefore, there is only one threshold for both comparisons, namely, the 
processing rate. Alternatively, it may be argued that Bakshi teaches comparing buffer 
usage to two different thresholds. However, these comparisons are not performed until 
after a determination is already made that the server is or is not overloaded. There is only 
one threshold for buffer usage if the server is overloaded and a different threshold for 
buffer usage if the server is not overloaded. Further, Bakshi does not teach or suggest 
evaluating buffer usage against a second threshold in response to detecting that buffer 
usage has passed a first threshold. Instead, the threshold to which buffer usage is 
compared is determined by whether or not a server is overloaded irrespective of any 
previous buffer usage evaluations. Accordingly, applicant finds no teaching or 
suggestion in Bakshi of a device configured to "in response to detecting that the server 
operation parameter has passed the first threshold value in a first direction: compare 
values of the server operation parameter to a second threshold value, wherein the second 
threshold value is different from the first threshold value," as is recited in claim 37. 



For at least these reasons, claim 37 is patentably distinguishable from the cited 
art. Further, as each of dependent claims 38 and 39 includes at least the features of the 
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independent claim upon which it depends, each of dependent claims 38 and 39 is 
believed to be patentably distinguishable for at least the above reasons as well. 

In view of the above, Applicant submits all claims are patentably distinguishable 
from the cited art. Accordingly, withdrawal of the rejections is requested. 
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CONCLUSION 

Applicant submits the application is in condition for allowance, and an early 
notice to that effect is requested. 

If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501505/5681- 
78600/RDR. 



Respectfully submitted, 



/ Rory D. Rankin / 

Rory D. Rankin 
Reg. No. 47,884 

ATTORNEY FOR APPLICANT(S) 



Meyertons, Hood, Kivlin, 

Kowert, & Goetzel, P.C. 
P.O. Box 398 
Austin, TX 78767-0398 
Phone: (512) 853-8800 

Date: April 15, 2008 
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